SGI Hot Mix 17

home *** CD-ROM | disk | FTP | other *** search

/ SGI Hot Mix 17 / Hot Mix 17.iso / HM17_SGI / html / vendors / softwarecom / demos / po31-releasenotes.txt < prev

Wrap

Text File | 1997-07-09 | 37KB | 787 lines

---------------------------------------------------------------------- WHAT'S NEW IN POST.OFFICE VERSION 3.1 ---------------------------------------------------------------------- These release notes: 1.) provide an overview of Post.Office version 3.1 2.) tell you where to find instructions for installing/upgrading your mail server 3.) describe the new anti-relay functionality 4.) describe the new mail blocking functionality 5.) offer detailed descriptions of features and enhancements introduced in version 3.1. 6.) provide information on bugs fixed in version 3.1 1. INTRODUCING POST.OFFICE 3.1 ---------------------------------------------------------------------- Post.Office version 3.1 is an upgrade to version 3.0 that offers new security features. To take full advantage of the system's current capabilities please review these Release Notes carefully, as they contain information on new 3.1 features that are not covered by the Post.Office manual set. (Note: The complete set of Post.Office manuals is included with each software package and is available from our web site at http://www.software.com.) Highlights of the Post.Office 3.1 release include: - An SMTP mail relay prevention feature that can be used to restrict the systems and/or users who may relay messages through Post.Office. - A mail blocking feature that can be used to block the delivery of all mail from a particular system, domain, E-mail address, or user name. Because blocking by IP address causes Post.Office to refuse network connections from the specified system, this feature can also be used to prevent "denial of service" attacks. - More flexible logging options for the SMTP-Accept module. This allows you to individually enable or disable logging for 13 different SMTP-Accept transactions. - Option for enabling or disabling the sending of a nightly report on mailing list activity to the list owner. This is configurable on a per-list basis. 2. INSTALLING/UPGRADING TO POST.OFFICE VERSION 3.1 ---------------------------------------------------------------------- The same software is used for installing Post.Office version 3.1 for the first time, upgrading from versions 2.0 and 3.0, or entering a new license number to accommodate additional accounts or mailing lists. The program checks to see if Post.Office already exists, then self-adjusts to perform the necessary installation or upgrade procedure. If you are installing Post.Office for the first time: ----------------------------------------------------- Locate the README file delivered with your software and follow the instructions defined within that document. Pay careful attention to any pre-installation requirements. If you are upgrading your mail server to Post.Office version 3.1: ----------------------------------------------------------------- THE POST.OFFICE UPGRADE OPERATION IS PERFORMING TASKS OF CONSIDERABLE COMPLEXITY INCLUDING DATABASE REGENERATION. TO ENSURE SUCCESS YOU MUST BACKUP YOUR SYSTEM PRIOR TO UPGRADING AND ALLOW ADEQUATE TIME TO COMPLETE THE POST.OFFICE UPGRADE OPERATION. IT IS ESSENTIAL THAT THE PROCESS RUN TO COMPLETION WITHOUT INTERRUPTION. For details on the recommended backup procedure, estimates on the time required to complete the upgrade process, and the upgrade instructions, please refer to the README file that was delivered with your software. Pay careful attention to any pre-installation instructions or related cautions. Those instructions must be observed in order to preserve the integrity of your system including any customized forms you may have created. 3. MAIL RELAY PREVENTION ---------------------------------------------------------------------- Version 3.1 includes new features for restricting the relaying of mail through Post.Office. Mail relaying occurs when a mail server is given a message which is not addressed to one of its local mail domains. This is among the most common activities of a mail server, and occurs whenever you send a piece of E-mail to a user in a remote mail domain. However, relaying mail through remote servers is a common tactic used by distributors of "junk" E-mail, and can cause your mail server's performance to suffer. 3.1 Introduction to Mail Relaying --------------------------------- Mail relaying is made possible by the openness of the SMTP protocol. By definition, SMTP servers accept network connections from mail clients and mail servers from around the network (or the Internet), and receive E-mail messages from the connecting system. If these messages are addressed to local users, the server will deliver them appropriately (for example, to a POP3 mailbox). However, if the messages are addressed to users in domains not controlled by the mail server, it must resend (relay) the messages to the appropriate mail server for delivery. For example, say your mail client uses as its SMTP (outgoing mail) server the host sparky.software.com, which runs Post.Office. When you send a piece of E-mail to your sister at jane.doe@thishost.someisp.net, your mail client opens an SMTP connection to sparky.software.com, gives Post.Office the message, and then closes the connection. Post.Office then determines that the message should go to thishost.someisp.net, and opens a connection to that host to give it the message. Because the message was not addressed to a user on sparky.software.com, the Post.Office on that host simply relayed the message on to its final destination; if it hadn't, none of your E-mails would ever get to your sister (or anyone else whose E-mail account is not on sparky.software.com). Although mail relaying is a common -- and, in most cases, essential -- activity for a mail server, it can become problematic if users abuse this functionality. The most common type of abuse occurs when users from outside of a domain use that domain's mail server as their SMTP server and send thousands of messages through it. Because the mail server must process and resend all of these messages, it may be temporarily unavailable to receive and/or deliver messages for the users who depend on this server for their E-mail. This type of abusive relaying can be easily done by even unsophisticated users, and the source of the messages can often be difficult to trace. Restricting mail relaying is therefore a serious issue for mail administrators. 3.2 Post.Office Anti-Relay Features ----------------------------------- The Post.Office anti-relay facility allows you to restrict mail relaying from specific systems or domains, or to disallow all relaying except for exempted systems and domains. You can also define the conditions under which restricted relay mail should be delivered. Post.Office can use any of the following rules to determine the handling of relay mail: * Completely unrestricted * Unrestricted with exceptions * Completely restricted * Restricted with exceptions You can specify the exceptions to these rules by IP address (to restrict or allow relay from a specific host) as well as by domain (to allow or restrict relay by all users in a specific domain). Because users can easily modify their mail client's return address to include any domain, restricting relay by IP address is the more precise method of the two. Note that "restricted" does not mean "prevented." When you restrict relay mail with the above rules, that relay mail may still be allowed for processing and delivery. A second set of rules associated with relay prevention allows you to specify the domains that should receive restricted relay mail (for example, in the case that your mail server is used as a backup for another domain). 3.3 SMTP Relay Restrictions Form -------------------------------- The Post.Office form for restricting mail relaying is the SMTP Relay Restrictions Form. This form is invoked from the System Configuration menu by clicking the Restrict Mail Relaying link (third from the top). This SMTP Relay Restrictions Form is divided between two sections. The first lets you define which type of mail relaying you want to restrict; this will include all of the types of relays that you want to prevent. The second part of the form allows you to determine who should receive the mail from transactions covered by the relay restrictions defined in the first part of the form; this allows you to permit selective delivery of otherwise denied relay mail. Remember that restricting relay mail DOES NOT by itself prevent the system at that address from relaying mail through Post.Office. It simply means such relaying will be allowed or denied according to the rules defined by the delivery options section of this form. - External Relay Restrictions: This radio button field allows you to specify rules for the restricting of relay mail. The four available selections are: * Don't restrict relay mail. This option allows all users to relay mail through your mail server without restriction. * Don't restrict relay mail except as indicated below. This option, which includes fields for specifying the systems and/or domains that are restricted from relaying, allows you to maintain a mostly open system which allows relaying except in special cases. When using this option, you would typically specify the IP address of a system that has been abusively relaying mail through your server, or the domain in the return address of these relayed messages. * Restrict all relay mail. This option restricts all relay mail, including relay mail sent by local users. Recall that a local user causes mail to be relayed whenever he or she sends a message which is addressed to a mail host other than his/her SMTP server. This option provides the ultimate in security, but in many cases is too restrictive. * Restrict relay mail except as indicated below. This option, which includes fields for specifying the systems and/or domains that are free to relay, allows you to maintain a mostly restricted system which allows relaying only in special cases. When using this option, you would typically enable the Local Mail Domains field to allow local users to relay mail, and also specify the IP address of systems which use your mail server as an SMTP hub. When specifying the IP addresses of systems which are or are not restricted from relaying, you can enter an IP address that uses 0 (zero) as a wildcard to specify an entire network. For example, restricting relay from the IP address 222.33.44.0 restricts all relay mail from any machine with an IP address in the class-C network 222.33.44. (Note: When allowing relay by IP address, you should always include the IP address 127.0.0.1, which refers to the host on which Post.Office is running.) When specifying the domains which are or are not restricted from relaying, you can enter a domain name that includes the * character as a wildcard to specify all of the hosts in a domain. For example, restricting relay from the domain *.promos.com restricts all relay messages whose return address includes these domains, such as: free.stuff@promos.com incredible.credit.card@credit.promos.com phone.service@phone.promos.com When relay restrictions are set using domain names, Post.Office checks the return address on the envelope of every message in the system against the list of allowed or restricted domains. Because a user can easily alter his/her return address to include any domain, using domains to restrict or allow relaying is not as secure as restricting by IP addresses. - Allow Mail Delivery To: This section of the form allows you to define which domains should or should not receive relay mail that you defined as restricted in the External Relay Restrictions section of this form. Note that relaying is not prevented -- even from restricted systems and/or users -- unless you also specify in this section of the form that delivery should not occur. There are two options for allowing the delivery of relay mail that you choose to restrict: * Any domain except those listed below. This option allows the delivery of all relay mail except when addressed to one or more specific domains. * No domain except those listed below. This option denies the delivery of all restricted relay mail, except when addressed to one or more specific domains. Included with this option are fields for allowing delivery of relay mail to Local Mail Domains and other domains. The Local Mail Domains option should always be enabled when using this delivery option, while the Additional Domains field should include domains for which your mail server is an MX backup. As in the relay restriction fields, you can enter a domain name in the delivery fields that includes a * character as a wildcard to specify all hosts in that domain. For example, denying delivery to the domain *.remote-net.com prevents the delivery of restricted relay mail addressed to this domain, or to any host in this domain. If delivery of a relayed message is prevented, Post.Office returns an error to the sender indicating that the attempt to relay mail to the specified domain was denied. The event is also entered in the Post.Office logs if SMTP RelayDenied logging is enabled. If a relayed message is addressed to multiple users, some of which are located in a denied domain, normal delivery will take place for the users whose domains are not denied. 3.4 Anti-Relaying Examples ------------------------- The following scenarios demonstrate the uses of the Post.Office anti-relay features, and give directions for dealing with specific situations of concern to mail administrators. - Scenario #1: "A particular system is using my server to distribute junk E-mail. How do I stop this?" By reviewing the Post.Office logs, you should be able to get the IP address of the offending system (this information is given with SMTP-Accept:Connect and SMTP-Accept:Receive log entries). To prevent relaying from this host, but otherwise leave your mail server available for relaying, execute the following steps in the SMTP Relay Restrictions Form: 1. Select the External Relay Restrictions radio button labeled "Don't restrict relay except as indicated below." 2. Enable the check box above the text field labeled "Restrict relay from these IP addresses," and enter the IP address of the offending system in this field. 3. In the delivery section at the bottom of the form, select the radio button labeled "No domain except those listed below." This selection allows you to deny delivery of the relay messages from the system whose IP address you specified in step 2. 4. Enable the check box field for the Local Mail Domains delivery option. This allows restricted system to continue to send messages to users within your local mail domain while still preventing this system from simply relaying messages through your mail server. 5. Enable the check box field for the Additional Domains option. In the text field below it, enter any additional domains that should be allowed to receive mail relayed through your server, such as sites for whom you are a backup MX site. (Note: If you want to disallow any incoming mail from a system -- even if that mail is addressed to a user in your local mail domains -- use the mail blocking facility described in section 4 of these release notes.) - Scenario #2: "Someone distributed the name of my mail server to people who relay junk E-mail, and now several users are relaying mail through my system, which is killing my server's performance." If you can't eliminate the problem of mail relaying on your server by restricting a few specific systems, change your relay settings to be more restrictive. Use the following settings in the SMTP Relay Restrictions Form: 1. Select the External Relay Restrictions radio button labeled "Restrict relay mail except as indicated below." 2. Enable the check box field labeled "Allow relay from these IP addresses" in the relay restrictions portion of the form. Enter the IP address(es) that reflects the IP addresses of your network, using a 0 (zero) as a wildcard where appropriate. For example, entering the IP addresses 222.33.44.0 127.0.0.1 will allow relay mail from any machine with an IP address in the class-C network 222.33.44, as well as from the server system itself (localhost). (Note: If you don't know (or can't know) all of the IP addresses of systems that should be allowed to freely relay mail through your server, use the "Local Mail Domains" and "Additional Domains" options to allow relay based on the domain of a message's return address.) 3. In the delivery section at the bottom of the form, select the radio button labeled "No domain except those listed below." 4. Enable the check box field for the Local Mail Domains delivery option. This allows restricted system to continue to send messages to users within your local mail domain while still preventing it from simply relaying messages through your mail server. 5. Enable the check box field for the Additional Domains option. In the text field below it, enter any additional domains that should be allowed to receive mail relayed through your server, such as sites for whom you are a backup MX site. - Scenario #3: "I want to restrict access to my mail server so that it allows ONLY the following: 1) all systems within my specific range of IP addresses can send mail to anyone; 2) all users in my local mail domains can receive mail from anywhere. How do I do this?" This configuration is the most secure (short of disallowing all relay), because it allows relaying only by systems within a network, as defined by a range of IP addresses. However, users with E-mail accounts on this server will not be prevented from receiving legitimate message from any E-mail sender. To set these relay and delivery rules, set the following in the SMTP Relay Restrictions Form: 1. Select the External Relay Restrictions radio button labeled "Restrict relay mail except as indicated below." 2. Enable the check box field labeled "Allow relay from these IP addresses" in the relay restrictions portion of the form. Enter the IP address(es) that reflects the IP addresses of your network, using a 0 (zero) as a wildcard where appropriate. For example, entering the IP addresses 222.33.44.0 127.0.0.1 will allow relay mail from any machine with an IP address in the class-C network 222.33.44, as well as from the server system itself (localhost). (Note: Do NOT enable the "Local Mail Domains" option in the External Relay Restrictions portion of the form. Enabling this option allows messages to be relayed according to the return address on the message's envelope; because a user can easily modify their return address to include one of your local mail domains, this method of restricting relay is not as secure as restricting by IP address.) 3. In the delivery section at the bottom of the form, select the radio button labeled "No domain except those listed below." 4. Enable the check box field for the Local Mail Domains delivery option. 5. Enable the check box field for the Additional Domains option. In the text field below it, enter any additional domains that should be allowed to receive mail relayed through your server, such as sites for whom you are a backup MX site. The effect of the above settings is that a message will NEVER be handled by Post.Office unless it is either 1) sent from a system whose IP address is within the specified network; or 2) addressed to a user in your local mail domains. Again, this is the most secure configuration for preventing mail relay. - Scenario #4: "The administrator of another domain is complaining that my mail server is being used to relay unsolicited mail to his users. How do I prevent outsiders from relaying mail to his server, while still allowing my own users to send mail there?" Although you'll probably want to deny outsiders from relaying mail through your system for security and performance reasons (as described in scenarios 1-3), you may decide to allow relaying unless the people who receive this mail complain about it. In this case, you can prevent relayed mail from going to the complaining domain by using the following settings in the SMTP Relay Restrictions Form: 1. Select the External Relay Restrictions radio button labeled "Restrict relay except as indicated below." 2. Enable the check box field labeled "Allow relay from these IP addresses" in the relay restrictions portion of the form. Enter the IP address(es) that reflects the IP addresses of your network, using a 0 (zero) as a wildcard where appropriate. For example, entering the IP addresses 222.33.44.0 127.0.0.1 will allow relay mail from any machine with an IP address in the class-C network 222.33.44, as well as from the server system itself (localhost). (Note: You can also enable the "Local Mail Domains" option in the External Relay Restrictions portion of the form if you want your users to be able to send mail to the domain in question. However, because a user can easily modify their return address to include one of your local mail domains, this method of restricting relay is not as secure as restricting by IP address.) 3. In the delivery section at the bottom of the form, select the radio button labeled "Any domain except those listed below." In the text area field below this radio button, enter the domain that you don't want to receive relayed mail. This means that restricted relay mail (that is, all relay mail from users outside of your network) will be delivered to all domains except the one you entered here. 4. MAIL BLOCKING ---------------------------------------------------------------------- In addition to restricting mail relaying, Post.Office 3.1 provides mail blocking functionality. Unlike anti-relay features, the purpose of mail blocking is to deny the delivery of messages which may be correctly addressed to users in local mail domains, but which are considered undesirable. The typical use of mail blocking is to prevent the delivery of unsolicited "junk" E-mail to users on your system. The Post.Office mail blocking facility also allows you to disallow all network connections from specific systems, as defined by IP address. In addition to blocking the acceptance of mail from these blacklisted systems, this allows you to prevent "denial of service" attacks, in which systems open many SMTP connections to a server for the purpose of denying access from other systems. (Note: Because mail blocking prevents the delivery of all messages (including legitimate E-mail) from the blocked systems and/or users, these features are recommended only in extreme cases.) 4.1 Mail Blocking Options Form ------------------------------ The Post.Office form for setting mail blocking rules is the Mail Blocking Options Form. This form is invoked from the System Configuration menu by clicking the Set Mail Blocking Options link (fourth from the top). - Block Incoming Mail From: No one This selection disables all mail blocking. This is the default mail blocking option. - Block Incoming Mail as Indicated Below This selection allows you to use four different criteria for blocking mail: by IP address, by E-mail address, by domain, and by username. Each type of blocking is explained below. - Blocking by IP addresses This option allows you to block all SMTP network connections to Post.Office from specific computers or networks, as defined by IP addresses. When accepting network connections, Post.Office checks the IP address of the connecting system against the list of IP addresses specified in this field; if the IP address of the connecting system is listed here, Post.Office refuses the connection. To block connections from an entire network, enter an IP address that uses 0 (zero) as a wildcard. For example, specifying the IP addresses 123.45.6.78 222.33.44.0 blocks all SMTP connections from the machine with IP address 123.45.6.78, or from any machine with an IP address in the class-C network 222.33.44. (Note: If you use backup mail servers for your domain, you should likewise configure these mail servers to refuse connections from these IP addresses.) When Post.Office refuses a connection from one of these blacklisted systems, an SMTP-Accept:ConnectionRefused event is entered in the Post.Office log (if you are logging this event). For example: 19970425164342-0700:SMTP-Accept:ConnectionRefused:[123.45.6.78] This log entry indicates that a system with a blocked IP address attempted to connect to Post.Office. The IP address in question is given at the end of the log entry. - Blocking by E-mail Address This option allows you to block incoming mail based on its envelope return address. When accepting messages, Post.Office checks the return address on the envelope of each message against the list of E-mail Addresses specified in this field; if the return address is listed here, Post.Office rejects the message by reporting to the sending system that the destination address(es) of the message do not exist. For example, specifying the E-mail addresses joe@junkmail.net cybermailer@promos.com free-money!@freecash.com blocks all messages which include any of these addresses in the envelope's return address information. When a message is blocked because of its return address, an SMTP-Accept:SenderBlocked event is entered in the Post.Office log (if you are logging this event). For example: 19970425164317-0700:SMTP-Accept:SenderBlocked: [10.3.91.11]:<joe@junkmail.net>:3 In this example, the address joe@junkmail.net was in the list of blocked addresses, and was prevented from submitting mail to Post.Office. The number 3 at the end of the log entry indicates the number of intended recipients of the blocked message. - Blocking by Domain This option allows you to block incoming mail based on the domain of its envelope return address. When accepting messages, Post.Office checks the return address' domain on the envelope of each message against the list of domains specified in this field; if the domains of the return address is listed here, Post.Office rejects the message and notifies the sender that he/she is not allowed to send mail to the destination address(es). For example, entering the domains promos.com freecash.com host1.someisp.net blocks all messages whose return address includes these domains, such as: incredible.credit.card@promos.com free-money!@freecash.com susie.queue@host1.someisp.net However, messages from jack.flash@someisp.net more-free-money!@more.freecash.com will NOT be blocked, because the domains of these addresses are not specified in this field. Note that in this field, unlike domain fields on the SMTP Relay Restrictions Form, wildcards can not be used with domain names to specify all hosts in a domain. When Post.Office refuses a message from one of these blocked domains, an SMTP-Accept:SenderBlocked event is entered in the Post.Office log (if you are logging this event). For example: 19970425164317-0700:SMTP-Accept:SenderBlocked: [10.3.91.11]:<offer@promos.com>:5000 In this example, the domain promos.com was in the list of blocked domains, and was prevented from submitting mail to Post.Office. The number 5000 at the end of the log entry indicates the number of intended recipients of the blocked message. - Blocking by username This option allows you to block incoming mail from E-mail addresses that include one or more specific user names (the username is the portion of an E-mail address to the left of the "@" symbol). This feature is useful if you want to block mail from distributors of "junk" E-mail who send messages from multiple domains but with the same user name. When accepting messages, Post.Office checks the return address username on the envelope of each message against the list of usernames specified in this field; if the username of the return address is listed here, Post.Office rejects the message and notifies the sender that he/she is not allowed to send mail to the destination address(es). To block all mail from a specific user name, enter the user name in this field. For example, specifying the user names incredible-offer john.doe blocks all messages whose return address includes these user names, such as: incredible-offer@junkmailer.com incredible-offer@megamailer.com incredible-offer@supermailer.com john.doe@megapromo.com john.doe@friendlyisp.net When Post.Office refuses a message from one of these blocked usernames, an SMTP-Accept:SenderBlocked event is entered in the Post.Office log (if you are logging this event). For example: 19970425164317-0700:SMTP-Accept:SenderBlocked: [10.3.91.11]:<incredible-offer@junkmailer.com>:30000 In this example, the user name "incredible-offer" was in the list of blocked user names, and was prevented from submitting mail to Post.Office. The number 30,000 at the end of the log entry indicates the number of intended recipients of the blocked message. 5. OTHER FEATURES NEW TO POST.OFFICE 3.1 ---------------------------------------------------------------------- Along with relay-prevention and mail blocking, Post.Office 3.1 includes two other new features: more flexible SMTP logging, and configurable sending of mailing list nightly reports. 5.1 Expanded SMTP Logging ------------------------- Control of SMTP logging has been improved by allowing Postmasters to individually log 13 different SMTP events, including three new events associated with mail blocking and relay prevention. On the Logging Options Form, 13 check box fields allow you to set or disable any of the following types of SMTP logging: SMTP Connect - records when an SMTP client makes a connection, and includes the client's IP address SMTP Close - records when an SMTP client closes the connection, and includes the total connection time (in seconds), number of messages sent, and the total number of bytes sent SMTP Abort - same as SMTP Close, but indicates that the client aborted its connection SMTP Timeout - same as SMTP Close, but indicates that the connection timed out SMTP Received - logs each message that is received, and includes the size, sender, and all recipients SMTP System - logs system failures that resulted in the inability to receive a message SMTP Alert - security-related warnings, such as when an SMTP client issues commands (such as "WIZ" or "DEBUG") which are intended to compromise server security SMTP ConnectionRefused - records network connections denied because the client's IP address matched a blocked IP address listed on the Mail Blocking Options Form SMTP SenderBlocked - records when a message is blocked because the sender address matched a blacklisted pattern, and includes the sender and the number of failed recipients SMTP RelayDenied - records attempted mail relaying that was denied because of settings in the SMTP Relay Restrictions Form, and includes the sender and the number of denied recipients SMTP QueueRequest - records client usage of the "QSND" command, which requests the processing of the mail queue SMTP Expand - records client usage of the "EXPN" command, which returns the primary address of an account, given a valid address for that account SMTP Verify - records client usage of the "VRFY" command, which is used to verify the existence of an account, given an E-mail address for the account 5.2. Configurable Sending of Mailing List Reports ------------------------------------------------- In order to keep mailing list owners up-to-date on the activity of their mailing list, Post.Office sends each list owner a nightly statistical report on mailing list usage for the pervious 24 hours. Included in this report are the number and size of messages submitted to the list, the numbers of subscription requests, unsubscription requests, and messages waiting for moderation, and a list of the top contributors to the list. These reports are sent at approximately midnight (according to the server system clock). Release 3.1 gives more flexibility to this feature by allowing Postmasters and list owners to enable or disable the daily list report on a per-list basis. In the Delivery section of both the Mailing List Data Form (Postmaster interface) and Mailing List Info Form (list owner interface), a new check box field labeled "Daily Statistics" controls the sending this report. Enabling this option will cause the list owner to receive the nightly report, while disabling this field turns off the report feature for this mailing list. 6. BUG FIXES IN VERSION 3.1 ---------------------------------------------------------------------- The following item (referenced by internal ID number) was recognized as a bug in a prior version of the Post.Office software. It has been remedied in version 3.1. 2311 - A mail routing hierarchy error in version 3.0 caused delivery to a local account (including accounts that use wildcard addressing) to be attempted prior to checking the SMTP Channel Alias Table for re-routing instructions. Re-routing mail according to the Channel Alias Table now occurs before all attempts at local delivery.